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REMARKS/ARGUMENTS 

These remarks are submitted responsive to the final office action dated February 
04, 2005 (Office Action). This response is filed in a timely fashion as a request for 
continued examination (RCE) to ensure timely prosecution and to ensure Applicants 
receive a response to the claims (as amended). No additional fee nor an extension of time 
is believed to be due. 

The Examiner objected to the phrase "intractable referential integrity" as it appears 
in claims 27- JO. In response, Applicants have amended these claims to exclude the 
objected phrase. The claim 27 and 28 amendments are supported by page 12, lines 8-10, 
by page 11, lines 24-26, by page 9, lines 15-19, by page 8, lines 29 to page 9, line 3, and 
throughout tho specification. The claim 29 and 30 amendments are supported by page 
10, lines 7-14, Applicants respectfully request the Examiner withdraw his objections in 
light of these amendments. 

The Examiner has rejected claims 1-4, 7-11, 13-16, 19-22, and 25-26 under 35 
U.S.C. § 103(;i) as being unpatentable over U.S. Patent No. 5,978,770 to Waytena, et al. 
(Waytena) in view of U.S. Patent No. 5,832,451 to Flake, et al (Flake). The Examiner 
has rejected claims 5-6, 12, 17, 23-24, and 17-30 under 35 U.S.C. § 103(a) as being 
unpatentable over Waytena in view of Flake and in further view of U.S. Patent No. 
5,499,359 to Vijaykumar (Vijaylcumar). 
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In response* Applicants have amended claims 1, 2, 4, 5> 8, 8, 12, 14, 19, 20, 23, 
26, and 27-30 to clarify various supported aspects of their invention. Amendments for 
claims 1 and 19 are supported by page 4, lines 2-20, by page 8, lines 3-5, by page 8 lines 
24-26, by FIGS 1-5, by page 13, lines 22-25, by page 8, lines 9-10, by page 10, lines 8- 
11, by page 14, lines 24-25, by page 11, lines 19-23, and throughout the specification. 
Amendments for claim 2 and 20 are supported by page 8, lines 20-23, by page 8, lines 
26-28, and by page 9, lines 26 to page 10, line 6. The Amendment for claim 4 is 
supported by page 4, lines 2-20. Amendments for claims 5 and 23 are supported by page 
10, lines 7-14, by page 13, lines 25-29, and by page 9, lines 18-25. Amendments for 
claims 8 and 26 are supported by page 13, lines 25-29, by page 10, lines 7-10, and by 
page 8, lines 15-18. Amendments for claim 9 are supported by page 9, line 2-4, by page 
9, line 16-18, by page 10, lines 10-11, by page 14, lines 24-25, and by page 11, lines 19- 
23. Claim 12 has been amended for consistency with amendments of claim 9. 
Amendments for claim 14 is supported by page 7-14, page 9, line 2-4, by page 9, line 16- 
18, by page 10, lines 10-1 1, by page 14, lines 24-25, and by page 1 1, lines 19-23. 

No new matter results from these amendments. 

The Applicants believe that the claim amendments will help clarify the 
distinctions between the Applicants' claimed invention and previous technologies. 
Applicants have invented an extension to an RDBMS system or the SQL language that 
includes the Imitation of a published RDBMS function in accordance with inventive 
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details described in the specification and explained in previous responses to office 
actions. 

Specifically, the claimed invention permits the RDBMS to associate a set of 
records included in a single RDBMS tabic to be associated with one another. 
Conventionally, no such association among records within the same RDBMS exists. 
After the association is established, a triggering event from an external source can 
identify one of the records in the set. In response to the triggering event, multiple ones of 
the records included records not identified can be automatically purged 

None of the cited references appear to provide teachings applicable to the RDBMS 
level of operation which would effectively be an extension of the SQL language. The 
cited references appear to be references dealing with user interactions with "front-end" 
applications, whereas the Applicants 1 claimed invention as cited in the currently pending 
claims is appl cable to a !f back-end" system (see page 4, lines 2-7 and page 5, lines 1 1-13 
of the Applicants 1 specification). Further, the cited references appear to not teach the type 
of single table "referential integrity" rules that are claimed by the Applicants, Instead, the 
references teach generic file manipulation techniques, which are very different to one 
skilled in the related art (databases) and are neither directed towards the same issue as the 
Applicants' claimed invention, nor do the cited references appear to provide analogous 
teachings. 
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A. Combinations of Waytcna and Flake fail to explicitly or implicitly teach 
claimed limitations. 

Claims 1-4, 7-11, 13-16, 19-22, and 25-26 under 35 U.S.C. § 103(a) as being 
unpatentable ever Waytena in view of Flake. 

Waytena teaches that multiple patrons having multiple personal communication 
devices can make reservations using a series of distributed computers (attraction 
computers) that are linked. Waytena's teachings are directed towards networking and 
distributed computing. Waytena directs no teachings towards databases in general or 
towards RDBMS's in particular and does not contemplate maintaining referential 
integrity in any fashion. 

Flake teaches a travel management information system (MIS) that can utili2e a 
database. Flake's implementation utilizes conventional database tools in implementing 
the disclosed MIS and are directed towards a particular implementation that relies upon a 
database. Flake provides no teachings or suggestions concerning expanding a RDBMS 
system. Flake does not contemplate intra-table referential integrity. Accordingly, Flake 
is an application (front end) that utilizes a conventional database (back-end). 

B. Vijaykumar fails to cure the deficiencies of Wayfena and Flake 

The Examiner has rejected claims 5-6, 12, 17, 23-24, and 17-30 under 35 U.S.C. § 
103(a) as being unpatentable over Waytena in view of Flake and in further view 
Vijaykumar. 
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Vijaykumar describes a method for improving inter-table referential integrity, 
which is the conventional referential integrity that exists for a RDBMS. Vijaykumar fails 
to provide teachings relevant to associations occurring within a single RDBMS table. 

C. Citations of the Examiner fall to teach the claimed art. 

In the Office Action, the Examiner repeatedly referenced front end, generic 
software appl ications and inferred that something related to back-end databases must be 
occurring duri ng front end processes. 

Applicants agree. In absence of other teachings, however, it should be inferred 
that conventional back-end database functions are being implemented in response to 
front-end utilizations of these databases. The Applicants' claimed teachings are not 
teachings known to be utilized in conventional databases. 

Because the claimed invention is not explicitly or implicitly taught by any 
combination of the cited references, the 35 U.S.C. § 103(a) rejections to claims 1-30 
based upon th ese references should be withdrawn, which action is respectfully requested. 

D. Failed Conference 

Applicants realize that their response is brief in some respects regarding how their 
claimed limitations are not anticipated by the cited art. The reason for this is that the 
Examiner's provided citations are unclear to the Applicants. This uncertainty was also 
shared by thf inventors, who are seasoned patent inventors and as such, were unable to 
provide guidiince regarding the rejections. 
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In order to resolve confusion, the Applicants contacted the Examiner and asked for 
clarification. Applicants explained how none of the cited references appeared to be 
directed at a back-end database problem. The Applicants asked the Examiner if the 
claimed scop? was of a scope other than what was intended or whether the cited 
references contained database teachings that were not apparent to the Applicants or the 
inventors. The Examiner indicated that the scope appeared to be proper, but that claim 
amendments vo same might be helpful to distinguish the claimed invention from the 
referenced art. Applicants believe the confusion regarding this Office Action relates to a 
misunderstanding pertaining to the field of relational databases. 

To expedite prosecution and to receive further guidance, Applicants requested a 
conference w th the Supervisor and the Examiner, hoping that the Supervisor could 
clarify the situation and determine the apparent source of confusion, so as to expedite 
prosecution aid permit the Applicants to properly advise the client in how best to 
proceed. This conference was denied, however, at the discretion of the Examiner. 
E. Relational Databases and the Claimed Invention 

Appliczmts have provided the following brief discussion concerning relational 
databases to clarify their understanding of what is meant by a back-end and RDBMS 
databases, as itsed in the Applicants 9 disclosure and as commonly used in the art. 

A "badc-end" refers to the section of a system which is not made available or 
visible to the general public such as a database which drives a website. Users and 
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applications (front-end systems) can interact with a back-end system using published 
functions having defined input and output parameters. Implementation details for how 
the back-end system performs programmatic actions when executing the published 
function are abstracted from the front-end and cannot be manipulated or modified by 
front end systems or users. 

An RDBMS is a database based on the relational model developed by E. F. Codd, 
A relational database allows the definition of data structures, storage and retrieval 
operations and integrity constraints. In such a database, the data and relations between 
them are organized in tables. A table is a collection of records and each record in a table 
contains the i*ame fields. Certain fields may be designated as keys, which means that 
searches for specific values of that field will use indexing to speed them up. Where fields 
in two different tables take values from the same set, a join operation can be performed to 
select related records in the two tables by matching values in those fields. Often, but not 
always, the fields will have the same name in both tables. 

Generally, duplicate information is not permitted within tables and each row of a 
table must hcive a unique key. The same columns generally apply to each record of a 
table. Also all the columns in a table are to be wholly dependent on the complete 
identifying piimary key and are dependent on no other keys (called third normal form or 
3NF). 
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RDBMS provided routines are used to maintain designated relationships between 
records in different tables. This is often referred to as inter-table referential integrity or 
simply referential integrity. Vijaykumar discloses an inter-table referential integrity 
technique. 

An example of referential integrity would be if two tables existed (football team 
table and person table). Each football team can include one or more people. The 
database can be an organization specific database, where the league having many 
different football teams has rules that only those people belonging to the organization can 
be a member of the football team. 

Having, established this scenario, assume a person uaing an application (front-end) 
linked to the football-league database (back-end) deletes a person from the organization. 
When this happens, the "link" for the removed person with the football team table is no 
longer valid. If the referential integrity rule called "cascading deletes" is enabled, the 
database will automatically remove the person from the football team table, when the 
person is removed from the person table. 

The Applicants claimed invention permits something similar to the "cascading 
deletes" to be established within a single RDBMS table. That is, a novel feature can be 
included within an RDBMS that associates records within a single table, (NOTE, 
because of the 3NF requirement for RDBMS tables, not every type of information can be 
dumped into a single table, as would be possible with a spreadsheet*) The airline 
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example in the disclosure on page 8, lines 14-28 may clarify the concept of intra-table 
referential integrity. Keep in mind, the context for the airline example is a relational 
database, where each table (due again to 3NF and RDBMS principles) is a defined entity 
having a unique primary key. 

For example, if you wanted to store people and job title in the same table, you 
would not be able to do so when a person can have multiple job titles without violating 
the 3NF constraint. The problem is not always resolved by adding an attribute in the 
person table for Jobl and Job2, since it may be possible for a person to have 3 jobs, or for 
multiple people working part time to share the same full time job. RDBMS principles 
such as referential integrity and 3NF handle these types of problems, which become very 
complex for targe databases. 

None of the cited references (other than Vijaykumar that teaches inter-table 
referential integrity) provide any insight useful to a .database designer, nor teach 
techniques thiit one of ordinary skill in the art would apply to RDBMS back-end systems 
if presented with the references. Waytena and Flake are simply directed to a different, 
and non-applicable, problem than that claimed by the Applicants. 

Applicants believe that this application is now in full condition for allowance, 
which action is respectfully requested. The Applicants request that the Examiner call the 
undersigned if clarification is needed on any matter within this Amendment, or if the 
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Examiner be lieves a telephone interview would expedite the prosecution of the subject 
application to completion. 



Respectfully submitted. 



Date: 
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Gregory A. Nelson, Registration No. 30,577 
Brian K. Buchheit, Registration No. 52,667 
AKERMAN SENTERFITT 
Customer No. 40987 
Post Office Box 3 188 
West Palm Beach, FL 33402-3188 
Telephone: (561) 653-5000 
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